-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NEW : Billing Term field database #32129
base: develop
Are you sure you want to change the base?
NEW : Billing Term field database #32129
Conversation
@@ -68,6 +68,7 @@ create table llx_facture_rec | |||
usenewprice integer DEFAULT 0, -- update invoice with current price of product instead of recorded price | |||
frequency integer, -- frequency (for example: 3 for every 3 month) | |||
unit_frequency varchar(2) DEFAULT 'm', -- 'm' for month (date_when must be a day <= 28), 'y' for year, ... | |||
billing_term integer DEFAULT 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you provide more information on the differznce between this field and the existing one fk_cond_reglement ?
May be provide 2 use case for each value ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have introduced a new field called billing_term to the model, with two possible values: postpaid or prepaid. By default, models are set to prepaid, meaning that invoice lines will reflect the dates of the current billing period when the invoice is generated. If the billing_term is set to postpaid, the invoice lines will instead correspond to the previous billing period. For instance, in a monthly billing cycle, a prepaid invoice for January would reflect January's dates, while a postpaid invoice generated in January would reflect December's dates. Similarly, for a quarterly cycle, a postpaid invoice generated for Q2 would cover the dates for Q1.
This differs from the fk_cond_reglement field, which governs the payment terms, such as whether payment is due upon receipt, within 30 days end-of-month, or within 10 days. While billing_term determines the period referenced in the invoice lines (current or prior), fk_cond_reglement defines when payment is expected, addressing distinct parts of the invoicing process.
Use Case Example: Consider a subscription service. For a prepaid model, the customer is billed at the start of January for services to be delivered in January. In contrast, for a postpaid model, the customer is billed at the start of January for services delivered in December. This allows flexibility in how the company aligns its invoicing practices with its operational or contractual obligations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see.
So the new field is not related to how the payment term will be filled but to how the field start/end on lines will be filled. You suggest 2 different rules but ibthink in a future we may have more.
So i suggest to rename the field into another name like
rule_for_lines_dates
Value can be 'prepaid or 'postpaid', so i suggest to use a varchar to store the rule. In a future, we may have complex rule, like prepaid:+3:-1 to have start date 3 days after and end date 1 day before for exemple.
@eldy is the explanation ok for you ? |
NEW|New Billing term field for model invoice
First PR for new field billing term in database : this field will allow to choice prepaid or postpaid for model invoice.